Summary

This PR implements one of the OG "yeah this will be extended in the future" tickets, allowing for related resources to be of any group, version or resource.

For this, the PublishedResource CRD has been extended to not take kind, but instead take group, version and resource. The old kind field is still supported, but deprecated, and can only handle ConfigMaps and Secrets, as before. If you want to have anything else, configure GVR instead.

(Why resource all of a sudden when everything else inside a PR is Kind-based? Because to figure out if a resource needs to be permission claimed, we would first need to figure out if that resource belongs to the same APIExport, and APIExports only contain resources and so we cannot resolve it before adding it, but to add it we need to resolve it and so Kinds are just not suitable here. I don't like it either, but ... yeah.)

Integration of custom GVRs into the syncer itself was pretty harmless, the more elaborate part was the APIExport controller which now has to figure out if a related resource points to a foreign resource (of another APIExport), so it can configure the permission claims correctly. Doing that while taking into account that PublishedResources are transmitted asynchonously (in the apiresourceschema controller) took a bit more code than expected.

Other than that, the change is relatively straightforward.

What Type of PR Is This?

/kind feature

Related Issue(s)

Fixes #109

Release Notes

* Related resources can now not just be ConfigMaps and Secrets, but any resource
* PublishedResources have a new `spec.synchronization.enabled` flag which can be used to use the agent to merely publish a CRD into kcp, but not actively sync it (for when the resource is meant to be a related resource of another PublishedResource)